Skip to content

media: Route HLS URLs to URL-player renderer - #11066

Closed
abhijeetk wants to merge 6 commits into
youtube:mainfrom
abhijeetk:url-player-6
Closed

media: Route HLS URLs to URL-player renderer#11066
abhijeetk wants to merge 6 commits into
youtube:mainfrom
abhijeetk:url-player-6

Conversation

@abhijeetk

@abhijeetk abhijeetk commented Jun 25, 2026

Copy link
Copy Markdown
Collaborator

Register kUrlPlayer as a conditional renderer factory using the
IsHlsUrl() predicate so HLS URLs select the URL-player path while
ordinary URLs continue using the Starboard renderer.

Enable CobaltContentRendererClient::OverrideDemuxerForUrl() to create
UrlPlayerDemuxer for HLS URLs.

Add RendererFactorySelectorTest coverage for .m3u8, hls_variant, and
non-HLS URLs.

Build: ninja -C out/tvos-arm64-simulator_qa cobalt nplb media_unittests

Bug: 512045535

Add use_starboard_url_player GN capability flag, derived from
use_starboard_media and tvOS platform detection. Expose it as
BUILDFLAG(USE_STARBOARD_URL_PLAYER) through build_config.h and
register matching Mojo enabled_features entry.

Add RendererType::kUrlPlayer = 13 to the C++ enum, Mojom enum,
traits mapping, and histogram. The new enum is gated behind
USE_STARBOARD_URL_PLAYER so non-tvOS builds are unaffected.

This establishes the capability boundary for all subsequent
URL-player CLs.

Bug: 512045535
Add mojom::Renderer::InitializeWithUrl(client, source_url) to deliver
the URL on the renderer Mojo pipe, keeping URL delivery and
initialization ordered on the same pipe.

Add UrlPlayerRenderer for tvOS URL-based playback via SbPlayerBridge
and UrlPlayerRendererWrapper as the Mojo service bridge. The wrapper's
InitializeWithUrl() sets the URL on the renderer internally then calls
Initialize().

MojoRendererService validates the renderer type and URL before
forwarding via static_cast, guarded by GetRendererType() == kUrlPlayer
and ReportBadMessage().

Bug: 512045535
Add UrlPlayerRendererClient to the tvOS URL-player build, which drives
URL-player playback over Mojo by calling InitializeWithUrl() directly
on the renderer pipe.

Add MediaResource::GetMediaUrl() behind USE_STARBOARD_URL_PLAYER so the
client can retrieve the media URL from the demuxer. The base
implementation returns an empty GURL; UrlPlayerDemuxer will override it
in a later CL.

Client unit tests are deferred to a later CL when all their
dependencies (InitializeWithStreamPointers, SetSourceUrl mojom) are
available.

Build: ninja -C out/tvos-arm64-device_qa cobalt media_unittests (pass)
Add CreateUrlPlayerRenderer to mojom::InterfaceFactory, guarded by
use_starboard_url_player, and route it through the renderer process,
browser media proxy, and GPU media service.

Add UrlPlayerRendererClientFactory, which creates a URL-player MojoRenderer
via MojoRendererFactory::CreateUrlPlayerRenderer and wraps it in
UrlPlayerRendererClient.

Add URL-player factory coverage and update fake InterfaceFactory
implementations in tests.

Build: ninja -C out/tvos-arm64-device_qa cobalt nplb media_unittests

Bug: 512045535
Add UrlPlayerDemuxer for tvOS URL-based playback. The demuxer
provides placeholder audio/video DemuxerStreams required by PipelineImpl
while the platform handles actual demuxing, and exposes the source URL
through GetMediaUrl().

Add IsHlsUrl() for detecting HLS URLs, plus a stub
OverrideDemuxerForUrl() in CobaltContentRendererClient. The override is
left inactive until the renderer routing CL lands.

Add kUrlPlayerDemuxer to DemuxerType, including the Mojom enum, traits
mapping, and histogram entry.

Build: ninja -C out/tvos-arm64-device_qa cobalt nplb media_unittests

Bug: 512045535
Register kUrlPlayer as a conditional factory with IsHlsUrl() predicate
in MediaFactory so HLS URLs select the URL-player pipeline while
ordinary URLs continue using the Starboard renderer.

Add routing tests for .m3u8, hls_variant, and non-HLS URLs to
RendererFactorySelectorTest.

Build: ninja -C out/tvos-arm64-device_qa cobalt nplb media_unittests (pass)
base::Unretained(this), client));
}

#if BUILDFLAG(USE_STARBOARD_URL_PLAYER)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks Chromium's mojo Renderer design, any non-standard ways should go to either mojom::StarboardRendererExtension or mojom::StarboardRendererClientExtension.

Modifying mojo_renderer and such codes are not upstreamable. Although we have some features (kCobaltBypassMojoForMedia) that modifying mojo_renderer, but this is only for experimental purposes.

As I'm not the owner from media side for URL player, I prefer to wait for @jasonzhangxx to back, so we can have a discussion about how to put URL player in the current chromium pipeline.

For me, there are several things I concern here:

  1. global url player build flag doesn't make sense to me, we should try to avoid adding new ones (even this makes tvOS url player life easier)
  2. we cannot modify chromium mojo renderer architecture design, see https://source.chromium.org/chromium/chromium/src/+/main:media/mojo/README.md for more information.

I think the current implement is too big for us to maintain, even this is maintained by your side, this makes Starboard codes harder to be upstreamed.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mojo renderer architecture

Thanks for raising this. I agree with the concern about adding URL-player-specific
API to the generic Mojo renderer path (mojo_renderer.cc, mojo_renderer_service.cc,
and renderer.mojom).

InitializeWithUrl() was added to keep URL delivery and renderer initialization
in a single call, but that does modify Chromium's generic Mojo renderer surface.
We can avoid that.

I can to move URL delivery to the Starboard-specific extension pipe, using
StarboardRendererExtension::SetSourceUrl() as in the earlier approach from
#10698. The renderer-side client already has access to the URL through
MediaResource::GetMediaUrl(), so it can send the URL over the Starboard
extension before calling the normal MojoRendererWrapper::Initialize() path,
similar to the existing OnGpuChannelTokenReady() ordering pattern.

This change would remove the InitializeWithUrl() plumbing from the generic
Mojo renderer classes/interfaces while keeping the current URL-player renderer
class split intact for now. In other words, this addresses the Mojo architecture
concern without folding the URL-player renderer/client/wrapper classes back into
StarboardRenderer in this PR.

I agree the broader class structure can still be discussed separately with
@jasonzhangxx , but this change should keep URL transport out of Chromium's generic Mojo
renderer API.

@abhijeetk abhijeetk self-assigned this Jul 2, 2026
@abhijeetk

Copy link
Copy Markdown
Collaborator Author

Thanks for all review comments. We are moving ahead with approach in PR #10698 (UrlPlayer using StarboardRenderer).
Closing this PR.

@abhijeetk abhijeetk closed this Jul 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants